Оценка персонала в Agile-командах

Начнем с главного: А можно ли вообще уйти от такой процедуры, как "оценка персонала"? Да, при наличии трех составляющих.

Критерии качества продукта

Если есть в процессе работы сотрудников критерии того, какого качества должен быть разрабатываемый продукт, то мы приходим только к двум выводам. Если продукт не обладает нужным качеством — значит, команда не обладает нужным уровнем квалификации. Если продукт получился нужного качества — значит, квалификация всех членов команды соответствует нужному уровню.

А если нет критериев качества нужного продукта, то кто заказывал такой продукт? И как он — этот заказчик — поймет, ему сделали хороший продукт или нет. В Agile эти критерии качества называются "Критерии приёмки" (acceptance criteria). И один из принципов Agile говорит: "Работающий продукт — основной показатель прогресса".
Поэтому, требуем от заказчика этой работы составить критерии качества продукта. И во время приемки получаем картину происходящего.

Циклы обратной связи

Scrum-Guides пишет: “Скрам-команды поставляют продукт... максимально используя возможности для получения обратной связи". Возможностей, где обратную связь давать коллеге можно, множество: от сессии парного программирования до ректроспективы, с глазу на глаз и/или в присутствии всей команды, в виде коучинга со стороны Scrum Master, в общем — много.

Итак, сотрудники регулярно говорят друг другу о своих ожиданиях, что их напрягает, чего им не хватает, и в чем им нужна помощь, и благодаря этой живой постоянной коммуникации нет необходимости во вмешательстве в команду со стороны с замечаниями.

Создаем процесс вместе с командой.

В результате последовательного негативного фидбека с постепенной эскалицией ("мы говорили, мы предлагали помощь, мы указывали на возможные последствия"), у зрелой команды должны появится полномочия удалять сотрудника из своей команды (из-за недостаточной квалификации, конфликтности и т.д.)

Выводы: правильная оценка персонала идет в процессе Agile-разработки

Понимаете, что получается? Никто не делает вид, что знает больше, чем сама команда. Если сотрудник находится внутри такой команды и поставляет такая команда регулярно продукт высокого качества, значит все идет так, как нужно. Agile HR вместе с командой пройдя этот путь, понимают, что теперь его главная задача, это зрелость команды, отсюда будет и качество продукта, и у всех членов команды регулярная обратная связь, и состав команды будет лучшим из возможных вариантов.

Это часть пути к самоорганизации команды, и так нужно поступать, из-за рекомендации следующего Agile-принципа: "Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд."

И здесь находится часть ответа на вопрос: “А как же с зарплатными ожиданиями?” Но это уже тема следующей статьи, где я поделюсь как мы в компании Hubber смогли решить этот вопрос, применяя принципы Agile.

Авторские статьи и комментарии к ним отображают исключительно экспертизу и точку зрения их авторов. Редакция Hurma System может не разделять мнение авторов.